IMS is a hierarchical database management system (HDBMS) developed by International Business Machines Corporation. IMS has wide spread usage in many large enterprises where high transaction volume, reliability, availability and scalability are of the utmost importance. IMS provides software and interfaces for running the businesses of many of the world's large corporations. However, companies incorporating IMS databases into their business models typically make significant investments in IMS application programs in order to have IMS perform meaningful data processing work particularly tailored to the needs of their respective enterprises. IMS application programs are typically coded in COBOL, PL/I, C, PASCAL, Java or assembly language. These application programs may perform IMS database functions by making Data Language One (DLI) calls to invoke needed IMS processing.
A batch IMS application program may have been developed to run as a stand-alone batch application outside of the IMS subsystem environment. These programs are characteristically invoked by specifying either “PARM=DLI” or “PARM=DBB” on the Job Control Language (JCL) EXEC statement and are henceforth referred to as DLI/DBB batch applications.
A batch IMS application may also be developed to run as a BMP batch application executing under the control of an IMS subsystem. These programs are characteristically invoked by specifying “PARM=BMP” on the JCL EXEC statement and are henceforth referred to as BMP batch applications.
A batch IMS application, either a DLI/DBB batch application or a BMP batch application, may be initially developed without the deployment of commit point processing. This may be a reasonable development approach at the time an application is originally developed. However, various conditions and environmental factors may change over time making it desirable to add commit point processing at some future time.
For example, a database may grow in size over time such that higher processing volumes are encountered. This can result in excessive contention for record locking resources (such as enqueue/dequeue blocks in IMS), or negatively impact response time where needed segments are locked out from other online applications. Furthermore, without taking frequent commit points, an application may experience a significant recovery cost in the event of an abnormal termination. This is because all of the work performed by the application must be backed out and redone going all the way back to the beginning of the job. This may be an unacceptable impact for an enterprise that is executing long running jobs.
Furthermore, it is frequently desirable for a particular DLI/DBB batch application to be converted to a BMP batch application. For example, program recovery procedures may be greatly simplified by changing from a DLI/DBB batch application to a BMP running under the IMS subsystem. This simplification occurs because the BMP execution environment provides for advanced logging capabilities utilizing a single system log as well as automatic data backout in the case of an abnormal termination. Furthermore, the ability to share critical IMS resources is enhanced under the IMS subsystem since resources may be locked and unlocked dynamically as required, rather than locking these resources for the entire duration of the DLI/DBB batch application. However, converting and running a DLI/DBB batch application as a BMP application may encounter unwanted and unnecessary abnormal terminations when commit point processing is not being performed by the batch application. This is because, within the BMP online processing environment, enqueue/dequeue blocks must be periodically and timely released by an application to avoid exhaustion of the finite supply of these blocks, and it is commit point processing that is used to accomplish this periodic and timely release.
Implementing commit point processing into an existing application may entail a time consuming and error prone manual process to comply with all commit point processing requirements within a BMP environment. It is an object of the present invention to assist the database administrator and database developer with a novel and non-obvious improvement for expediting this aspect of the conversion process.
Therefore, it is frequently necessary for commit point processing to be added to IMS batch applications for a variety of reasons, as briefly discussed supra. However, modifying an IMS batch application program to incorporate commit point processing may be a tedious, complex and error-prone process. For example, following a checkpoint call, all positioning within the IMS database is lost. Therefore, prior to proceeding with the business logic of the batch application at hand, it may be necessary to reestablish all positioning within the database to the state immediately preceding the checkpoint call.
Modifying an existing batch application to incorporate appropriate checkpoint calls and to reestablish proper positioning within a database can be an intimidating task for even the best of programmers. This is because substantial code changes must be made with exacting precision, possibly with minimal program documentation and/or loss of contact with the original developers of the batch application. Many IMS enterprises delay receiving, or entirely forego, the many advantages of commit point processing because of the extensive coding effort, discussed supra, involved with making the transition to a commit point enabled batch application.
Even for a new batch application, where the difficulty of inadequate documentation for an existing application is not a factor, the complexity of implementing commit point processing into the new application may also slow the development process, with significant increase in the coding and testing effort.
Accordingly, there is a great need for a solution to facilitate and expedite the addition of commit point processing to an existing batch IMS application, as well as solutions to speed the development of new batch applications requiring commit point processing.